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REMARKS 

Status : 

Claims 1-12 stand rejected under 35 U.S.C. §103(a) as being unpatentable over the teaching of 
U. S. Pat, No, 5,923.756 tu Shambroom, considered with the teaching of Schneier Applied 
Cryptography in view of the teaching of Balenson, " Privacy Enhancement for Internet 
Electronic Mail: Algorithms, Modes, and Identifiers", Network Working Group, Request For 
Comments (RhC) 1423, February 1993. 

Claims 1-12 as amended are presented for reconsideration as explained in the analysis that 
follows. 

Analysis; 

To start, it is helpful to look to the Schneier teaching at page 574 and the box 
representation of an X.509 certificate ot Figure24.2. The "Algorithm Identifier" box shows an 
"Algorithm" entry and a "Parameters" entry. The "Subject's Public Key" box shows an 
"Algorithm" entry, a "Parameters" entry and a "Public Key" entry- 

With this graphic in mind, more authoritative detail is provided regarding X.509 
certificates at "RFC 2459 Internet X,509 Public Key Infrastructure (January 1999) which is 
available at httn ://www.ietf.org/rtc/ (Selected pages are included in Appendix A hereto). 

At §4 J .2.7 "Subject Public Key Info" is discussed as follows: ""This field is used to carry the 
public key and identify the algorithm with tvhich the key is used. The algorithm is identified 
using the Algorithm Jdeniifier structure specified irt section 4. 1. 1.2, The object identifiers for the 
supported algorithms and the methods for encoding the public key materials (public key and 
parameters) are specified in section 7. 3. "(italics added to indicate quotation, holding added for 
empliasis) 
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There may be a host of alternatives for algoritluias but it is indicated that for a confdnning 
certificate, you get to select ONE with which the public key identified m the certificate is used. 

Again, this is not to say there are no alternatives. Indeed, the Balenson teaching of RFC 1423 
appears to be an effort to add more cryptugraphic algorithms. More to pick from. But, in an 
X.509 certificate, one algorithm is called for to be associated with the public key that is identified 
(see again the box representation of X,509 in the Schneier teaching). 

As indicated in Applicants specification, there are times when the sender may wish to 
communicate (see Alice and Bob discussion at p. 575 of the Schneier teaching) but not know the 
algorithms the other party supports, A safe choice is a commot) one such as RSA, but that might 
be less secure than other alternatives. 

Applicant has recognized that by using the certificate extensions described at §4. 1 .2.9 of RFC 
2459 (see Appendix A) to provide listG of public keys, each with associated encryption algoritlmij 
and a conresponding signature, the receiver may be enabled to select a more desirable trusted 
algorithm supported by the sender. Hence a certificate, by the use of permitted (under X509 v.3) 
extensions., but for an unintended purpose^ xutiy be able to offer plural public keys with associated 
cryptographic algorithms. Further, by making the certificate extensions non-critical (see section 
4,2 of RFC 2459). receivers unable to process the extensions may operate with the certificate and 
ignore the extensions. 

Now considering the applied references, it appears the Schneier teaching describes the usual 
certificates of the RFC 2459 document. The Balenson teaching appears related to improved 
algorithms and the ASN.1 identifiers mentioned are the same as called for in RFC 2459* 

The Shambroom teaching indicates that it identifies plural algorithms ( coL 10, lines 32-35 ) but 
doesn't teach how. It says the certificate "may resemble an ITU X.509 certificate'" What does that 
mean? It indicates there is but one public key (Shambroom col. 10, line 32), Where is each 
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algorithm associated with a public key that is signed for security as called for in. Applicant's 
claims? The Shambroom teaching seems a mere data Hat of algorithms suppoitecL Nul iii 
extensions and not associated with public keys or signatures. And, the Schneier and Balanson 
teachings, as indicated above, do not overcome the deficiencies of Shambroom In accordance 
with tliis aiidysis, il in believed that the prior art taken singly or together does not teach or 
suggest applicants approach to expanding the public key information, including associated 
algorithms and signatures, communicated by an X.509 certificate through the use of certificate 
extensions. Certificate extensions, a capability authorized in the X.509 v J specification detailed 
in RFC 2459, 

Applicant has amended the claims to more clearly emphasize the X.509 certificate structui^ and 
the inventive nse of certificate extensions to allow an expansion beyond the limits of the base 
X.509 certificate. This expansion involving respective public keys associated with cryptographic 
algorithms and identifiable with respective signatures to support establishment of a trusted 
conversation. 

In accordance with the foregoing, it is believed that die subject Application clearly identifies 
inventive subject matter not tauglit or suggcslcd in tlie prior art. Hence Applicant respectjfiiUy 
solicits withdrawal of the rejection of claims under 35 U.S,C. §103(a) and early notice that this 
case has been placed in condition for allowance. 

Respectfully Submitted, 


George E. Grosser 
Reg- No. 25,6291 

c/o IBM Corp. 

Dept. T81/Dldg. 503 PO Dox 121 95 
Research Triangle Park, NO 27709 
(919)968-7847 Fax 919-254-4330 
EMAIL: gegch@prodigy.net 

Sftrii^l No. 09/240, J?6.S 9 Docket CR9-98-095 
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4 Certificate and Certificate Extensions Profile 

This section presents a profile for public key certificates that will 
foster interoperability and a reusable PKI » This section is based 
upon the X.509 v3 certificate format and the standard certificate 
extensions defined in [X.509]. Th© ISO/IEC/ITU documents use the 
1993 vcrcion o£ ASM,1; wh^ilo this docum-snt up*?? tbo 1 3X.SN.1 
syntax, the encoded certificate and standard extensions are 
equivalent. This section also defines private extensions required to 
support a PKI ror the internet coiiutiuiU Uy - 

Certificates may be used in a wide rangq; of applications and 
environments covering a broed apectrum of interoperability goals and 
a broader spectrum of operational and assurance requiremeAts* The 
goal of this doouTnpnh is t n ftstabl.ish a common baseline for generic 
applications requiring broad interoperability and limited special 
purpose requirements. In particular, the emphasis will be on 
s-uppoi-ting the use o£ X.50 9 v3 ccrtifiostes for inforitial Inttsrnet 
elect-Toxiic mail/ IPsec, and WWW applications. 


4.1 Basic Certificate Fields 

The X-509 v3 certificate basic syntax is as follows. For signature 
calculation, the certificate is encoded using the ASN.l distinguished 
encoding rules (DER) {K-208]. AStJ.l DER encoding is a tog, length, 
value encoding system for each el^m^^nt . 

Certificate SEQUENCE { 

tbsCertif icate TBSCfc-'x LilicaLe, 

signatureAlgorithm Algorithmldentif ier, 
signatureVaiue BIT STRING } 


TBSCertif icate 


SEQUENCE { 


[0] 


version 
ser ialWumber 
signature 
issuea: 
validxty 
subject 

subjectPublicK^yinf o 
issuerUniqueXD [1] 

sub j ectUniquelD [ 2 ] 


CKtcneione 


[3] 


F.XPT.TCTT Version DEFAULT vl, 

Ccrtif icateSerialNumber, 

Algorithmldentif ier, 

Name, 

Validity, 

Name, 

Sub'j ect PubXicKeylnto, 

IMPLICIT Uniqueldentifier OPTIONAL, 

— If present/ version shall be v2 or v3 
IMPLICIT Uniqueldentifier OPTIONAL^ 

— If present, version shall be v2 or v3 
EXPLICIT Extensions OPTIONAL 

— If present, version shall be v3 


Housleyf et. al. standards Track [Page 15 J 


PA6E14/27\RCroAT9m5J11^^^ 


09/27/2085 23: 17 9199687847 


GEORGE E. GraSSER 


PAGE 15/27 

Page 15 of 121 


RFC 2409 Internet X.509 Public Key Infrastructure Januory 1909 


Version INTEGER { vl{0), v2(l), VjJ(2) ) 

CertificateSerialNumber ; INTEGER 

Validity SEQUENCE { 

notBeforc! Time/ 
notAfter Time ) 

Time : ;= CHUitJL { 

utcTime UTCTime, 
generalTiitie GeneralizedTine } 

Uniqueldentif ier : := BIT STRING 

Subject PubiicKeylnfo SEQUENCE { 

algorithm Algorithmldentif ier, 

subjectPublicKey BIT STRING } 

Extensions : := SEQUENCE SIZE (1-,HAX) OF Extension 

Ex:t«nsion : := SEQUENCE" { 

f-xl-nTD OBJECT IDENTIFIER, 

critical BOOLEAN DEFAULT FALSE, 

extnVgXue OCTET STRING } 

The following items describe the X.509 v3 certificate for use in the 
Internet . 

4.1.1 Certificate Fields 

The Certificate is a SEQUENCE of three required fields. The fields 
are described in detail in the following subsections. 

4.1.1*1 tbsCert if icate 

THe field contains rhe riamea of tliw suLj^iuL and iasuci, n public key 
associated with the subject, a validity period, and other associated 
information. The fields are described in detail in section 4.1»2; 
the tbscertificate may also include extensions which are described in 
section 4.2* 

4 , 1 * 1 » 2 signaturcAlgor ithm 

Thb; si9naLui:eAlcjorithTn £ield contains the identifier for the 
cryptographic algorithm used by the CA to sign this certificate. 
Section. 7.2 lists the supported signati:r(5 algorithms. 

An algorithm identifier is defined by the following ASN.l structure; 
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Mgorithmldentifier ::= SEQUENCE { 

algorithm Ui^vitcr iDENTiriER, 

parameters ANY DEFINED BY algorithrn OPTIONAL } 

The algorithm identifier is used to identify a cryptographic 
algorithm. The OBJECT IDEWTIFIER component identifies the algorithm 
(such a& DSA with SKA-l) . Th^a content.? nf i-hft npVir>n?^1 p;^r;^mp.f.firq 
field will vary according to the algorithm identified- Section 7.2 
lists the supported algorithms for this specification. 

This field MUST contain the same algorithm identifier as the 
signature field in the sequence tbsCertificate (see sec. 4.1-2»3)- 

4.1.1.3 signaturevalue 

The signaturevaliie field contains a digital signature computed upon 
the ASN.l DER encoded tbsCortif icate . The ASN,1 DER encoded 
LbsCei. Lificate is used as th« input to the signature function- Thia 
signature value is then ASN.l encoded as a BIT STRING and included in 
the Certificate's signature field. The details of this process are 
specified for each of the supported algorithms in jyection 

By generating this signature, a CA certifies the validity of the 
information in the tbsCertif icate field. In particular, the CA 
certifies the binding between the public key material and the subject 
o£ the certificate. 

4-1.2 TBSCertif icate 

The sequence TBSCertif icate contains information associated with the 
subject of the certificate and the CA who issued it. Hlvery 
TBSCertifioate contains the names of the subject and issuer, a public 
key associated with the subject, a validity period, a version number, 
anH nnmhfir; some may contain optional uniaue identifier 

fields* The remainder of this section describes the syntax and 
semantics of these fields, A TBSCertif icate may also include 
cxtcMions • EKtensicna for the Intornct PKI arc dcccritood. in Soction 
4.2. 

4,1,2,1 Version 

This field describes the version of the encoded certificate* When 
extensions are used, as expected in this profile, use X.509 version 3 
(value is 2) . If no extensions are present, but a Uniqueldentif ier 

ie pr©S©nt, us -si version 2 (valu© is 1) . T-P nnly h^iR-ir: f-iralH*^ ^rft 

present; use version 1 (the value is omitted from the certificate as 
the default value) . 
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Generation of version 2 certificates is not expected by 

4.1,2,2 Serial number 

The serial number ig an integar assigned by the CA to each 

certificate. It MUST be unique for each certifie^toi i^igued by a 

.given CA (i.e*^ the issuer name and serial number identify a unique 
certificate) . 

4.1-2.3 Signature 

Xhis field contains the algorithm identifier for the algorithm used 
by the CA to sign the certificate. 

This field MUST contain the same algorithm identifier as the 
signatureAlgorithm field in the sequence Certificate (see sec. 
>l. 1*1^2). Tho contcntc of the optional paramctcro field will vary 
according to the algorithm identified. Section 7,2 lists the 
supported signature algorithms. 

4.1.2.4 Issuer 

The issuer field identifies the entity who has signed and issued the 
certificate. The issuer field MUST contain a non-^empty distinguished 
name (DN) . The issuer field is defined as the X.501 typo Nam©. 
[X.501J Name is defined by the following ASN,1 structures: 

; RDNSequence } 

RDNSequence SEQUENCE OF RelativeDiStinguishedName 

RelativeDistinauishedName 

SET OF AttributeTypeAndValue 

AttributcTypcAndValuc is- SEQUENCE { 
type AttributeType, 
value AttributeValue ) 

AttributeType OBJECT IDENTIFIER 

AttributeValue any defined by AttributeType 
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Di rpr.tnryString ::= CHOICE { 
teletexString 
printableString 
uni versa lot ring 
utf 8String 
bmpString 


TeletexString (SIZE (l.,MAX)), 
PrintableString (SIZE (1 . .MAX) ) , 
UnivcroalString (SISE (l..tlAK))^ 
UTFSString (SIZE (1,. MAX}), 
BMPString (SIZE (1..MAX)) ) 


The Name describes a hierarchical nam© composed of attributes, such 
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as country name, and corresponding values, such as US. The type of 
the componcn-t AttributeValue is determined by uhe AttrlbuteType; in 
general it will be a DirectoryString. 

The DirectoryString type is defined as a choice of PjrintableString, 
TeletexString, BMPString, UTPestring, and UniversalString. The 
UTFSString encocting is the prRfftrrftti ^ncnH-ing, and all cortificat^e 
issued after December 31, 2003 WO'ST use the UTPSString encoding of 
DirectoryString (except as noted below) . Until that date^ conforming 

CTVe MUST ChOOOO fiiOm the following options when CxedUiny a 

distinguished name^ including their own: 

(a) if the cnaracter set is sufficient, the string MAY be 
represented as a PrintableString; 

(b) failing (a), if the BMPString character set is sufficient the 
string MAY be represented as a BMPString; and 

(c) failing (a) and (b) , the string MUST be represented as a 
OTFSString. If (a) or (b) as satisfied, the CA MAY still choose 
to repieatiuL the aLririg as a UTF6S"Cring. 

Exceptions to the December 31, 2003 UTF8 encoding reguiremt^nts are as 
follows: 


(a) CAs MAY issue "name rnllnvor" certificate? to support an 

orderly migration to UTFSString encoding. Such certificates would 
include the CA's UTFSString encoded name as issuer and and the old 
name Encoding eubject, or vicc-versa. 

(b) As stated in section 4.1.2.6, the subject field MUST be 
populated with a non-empty distinguished name matching the 
contents of the issuer field in all certificates issued by the 
subiect CA regardless of encoding. 

The TeletexString and UniversalString are included for backward 
compatibility, and should not be u^<™d for ccrtifiaates for new 
subjects. However, these types may be used in certificates where the 
name was previously established. Certificate users SHOUI^D be 
preparea to receive certificates witn these types. 
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In addition, many legacy implementations support names encoded in the 
ISO 8859-1 character set (LatinlString) but tag them as 
TeletexString. The LatinlString includes characters used in Western 
European countries which are not part of the TeletexString charcter 
set. Implementations that process TeletexString SHOni.n ht^ 
to handle the entire ISO 8859-1 character set, [ISO 8859-1] 

As noted above, distinguiehod namcc arc composed of attribute:? . This 
specification does not restrict the set of attribute types that may 
appear in names. However, conforming implementations MUST be 
prepared to receive certificates with issuer names containing the set 
of attribute types defined below- This specification also recommends 
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support for atid.i.tional attribute types - 

Standard sets of attributes have beon defined in the X.500 series of 
specifications. [X.520] Implementationa of this specification must 
prepared to receive the following standard attribute types in issuer 
names: country^ organization, organizational-unit r distinguished name 
qualifipr, stato or previnoQ name, and common name (e.g., "Suaeiii 
Housley") . in addition, impleirientations of this specification SHOULD 
be prepared to receive the following standard attribute types in 
iasufx iidiues; locality, title, surname, given name, initials, and 
generation qualifier {e.g., "Jr.", "3rd", or ^'IV) . The syntax and 
associated object identifiers (OIDs) for these attribute types are 
provided in the ASN.l modules in Appendices A and 

In addition/ implementation a nf th-i? specification MUST be prepared 
to receive the domainComponent attribute, as defined in (RFC 22A7] . 
The Domain (Nameserver) System (DNS) provides a hierarchical resource 
labeling oy£jtc:m. This attribut-c provides la a. uuriveniQnt mecnanism 
for organizations that wish to use DNs that parallel their DNS names. 
This is not a replacement for the dNSName component of the 
alternative name fleid- Implementations are not required to convert 
such names into DNS names* The syntax and associated OID for this 
attribute type is provided in the ASN.l modul«.q in App^ndie^s A and 
B. 

Certificate usors MUST be prepared to proccaa the isAuci- 
distinguished name and subject distinguished name (see sec. 4,1.2.6) 
fields to perform name chaining for certification path validation 
{siiBnti y^cLiori 6) . I'^ame chaining is perforcned J3y matching the issuer 
distinguished name in one certificate with the subject name in a CA 
certificate. 

This specification requires only a subset of the name comparison 
functionality specified in the X.BOO nf^ri^s of specifications. The 
requirements for conforming implementations arc as follows: 
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(a) attribute values encoded in different t^-pes (e.g., 
PrintableString and BMPString) may be asstJimed to represent 
different strings; 

(b) attribute values in types other than PrintableString are case 
sensitive (this permits matching of attribute values as binary 
objects) ; 

ir.) flt.t-.rihiite v;iln*3.r; in PrintableString are not case ooncitivc 
(e.g., "Marianne Swanson'* is the same as "MARIANNE SWANSON") ; and 

(d) attribute values in PrlutdbltiSUAiay are compared after 
removing leading and trailing white space and converting internal 
substrings of one or more consecutive white space characters to a 
sj^ngle apace. 
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These name comparison rules permit a certificate user to validate 
certificatos issued using languages or encodings uniTamiliAi. Lo Uhe 
certificate user. 


lii dcJOiLiou, in^lementations or this specification MAY use these 
comparison rules to process unfamiliar attribute types for name 
chaining. Thj,s allows implementations to process certificates with 
unfamiliar attributes in the issuer name. 


Nnt^i thai- thp comparison rules defined in the X.500 aerie.? of 
specifications indicate that the character sets used to encode data 
in distinguished names are irrelevant. The charactcsrs themselves are 
compared without regard to eauudlny. Iiuplementations of the profile 
are permitted to use the comparison algorithm defined in the X,500 
series, 5uch an implementation will recognize a superset of name 
matches recognized by the algorithm specified above. 


4.1.2.5 Validity 


The certificate validity period is the time interval during which the 
CA warranto that it will maintain information abouL Lhy status of the 
certificate. The field is represented as a SEQUENCE of two dotes; 
the date on which the certificate validity period begins (notBefore) 
and the date on wnich the cerciricate validity period ends 
(notAfter) . Both notBefore and notAfter may be encoded as UTCTime or 
GeneralizedTime. 

CAs conforming to this profile MUST always encode certificate 
validity HAtf^j!! through th© year 2049 a.9 UTCTim©; certificate; validity 
dates in 2050 or later MUST be encoded as GeneralizedTime. 
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4.1*2.5,1 UTCTim.e 

Tne universal time type, UTCTime, is a standard ASN.l type intended 
for international applications where local time alone is not 
adequate. UTCTime specifies the year throuqh the two low order 
digits and time is specified to the precision of one minute or one 
second* UTCTime includes either Z (for Zulu, or Greenwich Mean Time) 
or a tim<5 dif f erential - 

ror the purposes of this profile, UTCTime va.lue3 MUST be expressed 
Greenwich Mean Tlxuw (Zulu) and MUST Include seconds (i.e., times are 
YYMMDDHHMMSS2) , even where the number of seconds is zero. Conforming 
systems MUST interpret the year field (VY) as follows: 

Where YY is greater than or equal to 50, the year shall be 
interpreted as 19YY; and 

Where YY is less than SO, the year shall be interpreted os 20YY, 
4-1-2.5.2 General! zedTime 
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Tho goA^ralised tliTVG type, CcncraliscdTime/ ia a standard ASN-1 Cyp« 
for variable precision representation of time. Optionally, the 
GenaralizedTime field can include a representation of the time 
differential between local and Greenwich Mean Time. 

For the purpose3 of this profile, GeneraliaedTlmP! vi^lues MOST be 
expressed Greenwich Mean Time (Zuly) and MUST include seconds {i.e*, 
times are YYYYMMDDHHMMSSZ ) , even where the number of seconds is zero. 
GeneralisedTim© values MUST NOT include fractional seconds, 

4*1.2.5 Subject 

Th$ subject field identifies the entity associated with the public 
key stored in the subject public key field. The sublect name may be 
carried in the subject field and/or the subjectAltName extension. If 
the subject is a CA (e.g., the basic constraints extension; as 
discussed in 4.2.1.10, i pvpi^ic^nt and thi& valu^ of ca is TRUE,} then 
the subject field MUST be populated with a non-empty distinguished 
name matching the contents of the issuer field (see sec- 4,1.2.4) in 
all certificates irsijucd by the subject CA. 11 subject naming 
information is present only in the subjectAltName extension (e.g., a 
key bound only to an email address or URI), then the subject name 
MUST be an empty sequence and the subjectAltName extension MUST be 
critical. 
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Where it is non-empty, the .ql3bj(=!r.^ fi(?ld MUST contain An x-500 
distinguished name (D^3) - The DN MUST be unique for each subject 
entity certified by the one CA as defined by the issuer naiae field. A 
CA may issue more than on© c&rt if ICciLt.' wlutj Lhe same DN to the same 
subject entity. 

The subject name field is defined as the X.501 type bJame. 
Implementation requirements for this field are those defined for the 
issuer field (see sec. 4.1.2,41. When encoding attr-ihn^R v<»lu©s o£ 
type DirectoryString, the encoding rules for the issuer field MUST be 
implemented. Implementations of this specification MUST be prepared 
to receive subject names containing the attribute types i.t;iqulj:*ed for 
the issuer field. Implementations of this specification SHOULD be 
prepared, to receive subject names containing the recommended 
attribiate types for the issuer tield. The syntax and associated 
object identifiers (OlDs) for these attribute types are provided in 
the ASN.l modules in Appendices A and B. Implementations of this 
specification may use these comparison rules to process unfamiliar 
attribute types (i.e., for n^jme chaining). This allows 

implementat i onei trt pTone^s.s certificates with unfamili.-ir attributca in 
the subject name. 

In addition, legacy implementations exisL wht:j:« isji RFC 822 name is 
embedded in the subject distinguished name as an EmailAddress 
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attribute. The attribute value for Email Address is of type lASString 
to permit inciluBicin of the uhai.at;Lfcsx- '@'/ which is not part OI tue 
PrintableString character set.. Erqail Address attribute values are not 
case sensitive (e.g., "fanfeedback@redsox.com" is the same as 
"FANFEEDBACK@REDSOX . QO^") . 

Conforiaincr impl«2Tne.ntations generating now r.ft^rtif icat^s with 
electronic m&ii addresses MUST use the rfc822Nairie in the sub;iect 
alternative name field (see sec. 4.2,1.7) to describe such 
identitico. Simultaneous? inclusion of the EraciilAdU/.eas attribute In 
the subject distinguished name to support legacy implementations is 
deprecated but permitted. 

4.1.2.7 Subject Public Key Info 

This field is used to carry Lhe public key and identify the algorithm 
with which the key is used. The algorithm is identified using the 
al gorithmld^ntifiar structure spacifiod in i*cction 4-1-1.^. The 
Object identifiers for the supported algorithms and the methods for 
encoding the public key materials (public key and parameters) are 
specified In it^i^ll^ii 7.3. 
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4.1,2.8 Unique Identifiers 

These fields may only appear if the version is 2 or 3 (see sec. 
4.1-2*1). The subject and issuer unique identifiers are present in 
^hft c<?rtificate to handle the possibility of rcuo© of subject and/or 
issuer names over time. This profile recommends that names not be 
reused for different entities and that internet certificates not make 
use of unique .tdentifiers . CA3 conforming to this profile SHOULD NOT 
generate certificates with unique identifiers. Applications 
conforming to this profile SHOULD be capcxble of parsinq unique 
identifiers and making comparisons* 

4.1.2-9 Extens ions 

This field may only appear if the version is 3 (see sec. 4.1.2.1). 
If present/ thi^ JJield is a SEQUENCE uT one or more certificate 
extensions. The format and content of certificate extensions in the 
Internet PKI is d^jfined in section 4.2. 

4*2 Standard Certificate Extensions 

The extensions defined for X-509 v3 certificates provide methods for 
associating additional attributes with users or public keys and for 
managing the certification hierarchy. The X^SOS v3 aertifiCdLe 
format also allows communities to define private extensions to carry 
information unique to those communities. Each extension in a 
cer tiriuaLa luay L;e U^rsignated as critical or non-critxcai * A 
certificate using system MUST reject the certificate if it encounters 


PAGE 22/27'RCVDAT9/27l200511:1_5:34PM [Eastern Daylight Tiine]*SVR:USPTOfFX^^^^ 


69/27/2005 23:17 9199687847 


GEOR^ E. GraSSER 


PAGE 23/27 

Page 23 of 121 


a critical extension it does not recognize; however, a non-critical 
extension nrny ignored i£ it ic not recognised- Thcs followlny 
sections present recommended extensions used within Internet 
certificates and standard locations for inf orrnation • Corninunitiea may 
t!l«cl Lo use additXonal extensions; however, caution should be 
exercised in adopting any critical extensions in certificates which 
might prevent use in a general context. 

Each extension includes an OID ond an ASN.l structure* When an 
extension ;=if>pft^rs in a certificate, th© OID appcarc as the field 
extniD and the corresponding ASN.l encoded structure is the value of 
the octet string extnValue. Only one instance of a particular 
extension may appear in a parLluul<ii c^yrLif icate . For exampXe, a 
certificate may contain only one. authority key identifier extension 
(see sec- 4*2-1,1) , An extension includes the boolean critical, with 
a default value of FALSE, The text for ©ach extension specifies the 
acceptable values for the critical field. 
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rtnnfnTTTi-i ng CA9 MLISt support koy identifio^rc (ccc ncc- -9.2,1.1 ond 
. 4.2.1.2), basic constiraints (see sec, 4.2.1.10}, key usage (see sec. 

4.2.1.3), and certificate policies (see sec- 4*2.1.5) extensions. If 
the CA is3utta u«xLiricate£3 with an empty sequence tor the subject 
field, the CA MUST support the subject alternative name extension 
(see sec. 4,2.1.7). Support for the remaining extensions is 
OPTIONAL. Conforming OAs may support extensions that are not 
identified within this specification; certificate issuers are 
cautioned that marlcina such extensions as nrit-^nal may inhibit 
interoperability . 

At a minimum, applications confonning to this ^iuliie MUST recognize 
the extensions which must or may be critical in this specification. 
These extensions are: key usage (see sec. 4.2*1.3), certificate 
policies (see sec. 4.2.1.5), the subject alternative name (see sec. 
4.2.1.7), basic constraints (see sec, 4.2.1.1,0), name constraints 
(see sec. 4.2.1.11)^ policy constraints (see sec 4,2,1.12), and 
extended key usage (see sec. 4.2.1.13). 

In addition, thie: profile RECOMMENDS application supporL £uL Lhfcj 

authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2) 
extensions . 

4.2.1 Standard Extensions 

This section identifies standard certificate extensions defined in 
[X.5Q9] for use in the Internet PKI, Each extension is associated 
with an OID defined in [X. 509.1 - Th*i»sR nrns are members of th« id-cs 
arc, which is defined by the following: 

id-cc OBJECT IDENTIFIER j (joint iao Ccitt(2) ds(3) 29} 
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4.2.1.1 Authority Kisy Identifier 

The authority key identifier extension provides a means of 
identifying the public key corresponding to the private key used to 
sign a certiricate. This e5<T:ension is used where an issuer has 
multiple signing keys (either due to multiple concurrent key pairs or 
due to changeover) . The identification may be based on eithfir th(^. 
key identifier (the subject key identifier in the issuer's 
certificate) or on the issuer name and serig.! number - 

The keyldentif ier field of the authorityKeyldentif ier extension MUST 
be included in ail certificates generated by conforming CAs to 
facilitate chciiii bullcjiuy. There is one exception; wnere a CA 
distributes its public key in the form of a "self -signed" 
certificate, the authority key identifier may be omitted. in this 
case, the subject and authority key identifiers woul,d be identic5i.l» 
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The value of the keyldentif ier field SHOULD be derived from tbe 
public key used to verify the certificate's signature or s mftfhrjH 
that generates unique values. Two common methods for generating key 
identifiers from the public key are described in (sec. 4,2.1.2). One 
r*r>mmrjn method for generating unique values iEdcecribcd in (sec* 
4.2,1.2). Where a key identifier has not been previously 
established;, this specification recommends use of one of these 
ui<?LJj.udtj for generauing keyiaenLif iers . 

This profile recommends support for the key identifier method bv all 
certificate users. 

This extension MUST NOT be marked cri1--if-!^l . 

id-ce-authorit:yKeyIdentifier OBJECT IDOTTIFIER ::= { id-ce 35 } 

AuthorityKeyldentif ier : := SEQUENCE { 

keyldentifier {0] Keyldentif ier OPTlQNALr 

autnorityCertlssuer [1] GeneralNames OPTIONAL, 

authorityCertSerialNumber [2] Certif icateSerialNumber OPTIONAJ^ } 

Keyldentifier : := OCTET STRING 

4.2.1.2 Subject Key Identifier 

The subject key identifier extension provides a means of identifying 
certificates that contain a particular public Icey. 

To facilitate chain building, this extension MUST appear in all con- 
forming CA certificates, that is, all certificates including the 
basic constraints extension (see sec- 4 - 2 . 1 . 10) where the value of oA 
is TRUE* The value of the snhjent key identifier MUST be the value 
placed in the key identifier field of the Authority Key Identifier 
extension (see sec. 4.2.1.1) of certificates issued by the subject of 
thi^ certificate. 
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For CA certificates, subject key id.entif iers SHOULD be derived from 
th^ public key or a method that generates unique values. Two (junuinjji 
methods for Qfeneracing key identifiers from the public key are: 

(1) Tne keyldentitier is composed of the 160-bit SHA-I hash of the 
value of the BIT STRING subjectPublicKey [excluding the tag, 
lencfth, and number of unused bits) * 

(2) The keyldentifier is composed of a four bit type field with 
the vali;i® 03.00 followed by the Icact cignificont 60 bits of the 
SRA-1 hash of the value of the BIT STRING subjectPublicKey . 
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One common method for generating ui'iique veilu^&* la a monotomlcally 
increasing sequence of integers. 

For end entity certificates, the subject key identifier extension 
provides a means for identifying certificates containing the 
particular public key used in an application- Wherft An f*nd r?ntity has 
obtained multiple certificates, especially from multiple C7is, the 
subject key identifier provides a means to quickly identify the set 
of certificates containing a particular public key- To assist 
applications in identif iciation the appropriate end entity 
certificate, this extension SHOULD be included in all end entity 
certificates . 

For end entity certificates, subject key identifiers SHOULD be 
derived from the public key. Two common methods for generating key 
identifiers from the public key are identif ed above. 

Where a key identifier has not been previously established, this 
specification recommends use of one of these methods for generating 
keyldenuiliei-a . 

This extension MUST NOT be marked critical. 

id-ce-subjectKeyldentifier OBJECT IDENTIFIER : :^ { id-ce 14 } 

SubjectKeyldentif ier ; Keyldentifier 

4.2.1.3 Key Ugqgei 

The key usage extension d<5yfines the purpose (e.g,, oncipherment , 
signature, certiticate signing) ot the key contained in the 
certificate. The usage restriction might be employed when a key that 
could be used for more than one operation is to be restricted. For 
example r when an RSA key should be used only for signing, the 
digitalSignature and/or nonRepudiation bits would be asserted . 
T.-ilfPwisjp, when an RSA key should be usQd only for key inan^igoTnont, tho 
keyEncipherment bit would be asserted, when used, this exte-nsion 
SHOULD be marked critical. 

id-ce-keyUsage OBJECT IDENTIFIER : := { id-ce 15 ) 
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KRyUsage : :^ BIT STRING { 

, digitalSignature (0), 

nonRepudiation (1), 

keyEnciplit:iii[(#xiL {2), 

dataEncipherment (3) , 

keyAgxeement (4), 

keyCertSign (5), 
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cRLSign (6), 
encipherOnly (7), 
decipherOnly (8) } 


Bits in the KeyUsage type are used as follows: 

The digitalSignanur^i oit is asserted when the subject public key 
is used with a digital signature mechanism to support security 
services other than non-repudiation (bit 1). certificate signing 
(bit 5}, or revocation information signing (bit 6), Digital 
signature mechanisms are often used for entity authentication and 
data origin sni-hpnt ication with integrity. 

The nonRepudiation bit is asserted when the subject public key is 
used Lu vcsj^ity (Jlgital signatures used to provide a non- 
repudiation service which protects against the signing entity 
.talsely denying some action, excluding certificate or CRL signing. 

The keySncipherment bit is asserted when the subject public key is 
used for key transport. For example, wh^n ^rx RSA key is to be 
used for key nanagementr then this bit shall asserted. 

The dataEncipherment bit is assert-ed whuii Lhe subject public key 
is used for enciphering user data, other than cryptographic keys. 

The KeyAgreement bit Is asserted when the subject public key is 
used for key agreement. For example, when a Dif f ie-Hellman key is 
to be U5«2d for key management, then this bit shall asserted. 

The keyCertSign bit is asserted wh<sn the subj(3C!t public key is 
used £qx verifying a signature on certificates. This blL ju^y only 
be asserted in CA certificates. 

The cRLsiyii blL is asserted when the subject public key is used 
for verifying a signature on revocation information (e,g., a CRL) , 

The meaning of the encipherOnly bit is undefined in the absence of 
the keyAgreement bit. When the encipherOnly bit is asserted and 
the keyAgreement bit is also sftf^ thts> subject public key may bo 
used only for enciphering data while performing key agreement. 

Th« JCti^Sining of tbc dcciphcrOnly bit is undefined lii LLl: ybaence of 

the keyAgreement bit. When the decipherOnly bit is asserted And 
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the IceyAgr98TTient bit ia also set, the subject public key may be 
used only fnr H*>oiph^jring data while performing ^ey dyc-eement. 
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This profile doc53 not restrict Llit? t^ymbinatlons of bits that may be 
set j.n an instantiation of the keyUaage extension. However, 
appropriate values for keyUaage extensions for particular alaorithms 
are specitied in section 7,3. 

4,2.1.4 Privates Key Usage Period 

This profile recommends against the use of this extension, CAs 
nnnforming to this profij.c MUST NOT gennrote cexLiricates wj.cn 

critical private key usage period extensions. 

Th^ private key usage period extension allows the certificate issuer 
to specify a different validity period for the private key thsn the 
certificate. This extension is intended for use with di.qU'A^ 
signature keys* This extension consists of two optional components, 
notBefore and notAfher. The private key associated with the 
cert-i f 1 r.flhR .should not bo usod to sign cbjcctcj before or afLei. Lhi- 
times specific5d by the two components, respectively. CAs conforming 
to this profile MUST NOT generate certificates with private key usage 
period ejtLt;it::iitjn3 unless at leasr one of tne two components is 
present. 

Where used^ notBefore and notAfter are represented as GeneralizedTime 
and MUST be specified and interpreted as defined in section 
4.1.2.5.2. 


id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER : ;= { id-ce 16 } 

PrivateKeyUsagePcriod SEQUENCE { 

notBefore [0] General izedTim© OPTIONAL, 

notAlter ll\ GeneralizedTime OPTIONAL } 

4.2.1.5 Certificate Policies 

The certificate policies extension contains a sequence of one or more 
policy information torms/ each cf which consists of an objecL 
identifier (OID) and optional qualifiers. These policy information 
terms indicate the policy under which the certificate has been issued 
and the purposes tor which th<5 certiticate may be used. Optional 
qualifiers, which may be present, are not expectad to change the 
definition of the policy. 

Applications with specific policy requirements are expected to have a 
list of those policie.s whirh thpy will <*ccept and to compare tho 
policy OIDs in the certificate to that list. If this extension is 
critical, the path validation software MUST be able to interpret this 
CKtonoion (including the optional, qualifier), or MUST reject Lhe 

certificate* 
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